<!DOCTYPE html>
<html>
<!-- Created by GNU Texinfo 7.1, https://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<!-- Copyright © 1988-2023 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "Funding Free Software", the Front-Cover
Texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below).  A copy of the license is included in the section entitled
"GNU Free Documentation License".

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU
     software.  Copies published by the Free Software Foundation raise
     funds for GNU development. -->
<title>Unary and Binary Expressions (GNU Compiler Collection (GCC) Internals)</title>

<meta name="description" content="Unary and Binary Expressions (GNU Compiler Collection (GCC) Internals)">
<meta name="keywords" content="Unary and Binary Expressions (GNU Compiler Collection (GCC) Internals)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta name="viewport" content="width=device-width,initial-scale=1">

<link href="index.html" rel="start" title="Top">
<link href="Option-Index.html" rel="index" title="Option Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="Expression-trees.html" rel="up" title="Expression trees">
<link href="Vectors.html" rel="next" title="Vectors">
<link href="Storage-References.html" rel="prev" title="Storage References">
<style type="text/css">
<!--
a.copiable-link {visibility: hidden; text-decoration: none; line-height: 0em}
div.example {margin-left: 3.2em}
span:hover a.copiable-link {visibility: visible}
-->
</style>


</head>

<body lang="en">
<div class="subsection-level-extent" id="Unary-and-Binary-Expressions">
<div class="nav-panel">
<p>
Next: <a href="Vectors.html" accesskey="n" rel="next">Vectors</a>, Previous: <a href="Storage-References.html" accesskey="p" rel="prev">References to storage</a>, Up: <a href="Expression-trees.html" accesskey="u" rel="up">Expressions</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<h4 class="subsection" id="Unary-and-Binary-Expressions-1"><span>11.6.3 Unary and Binary Expressions<a class="copiable-link" href="#Unary-and-Binary-Expressions-1"> &para;</a></span></h4>
<a class="index-entry-id" id="index-NEGATE_005fEXPR"></a>
<a class="index-entry-id" id="index-ABS_005fEXPR"></a>
<a class="index-entry-id" id="index-ABSU_005fEXPR"></a>
<a class="index-entry-id" id="index-BIT_005fNOT_005fEXPR"></a>
<a class="index-entry-id" id="index-TRUTH_005fNOT_005fEXPR"></a>
<a class="index-entry-id" id="index-PREDECREMENT_005fEXPR"></a>
<a class="index-entry-id" id="index-PREINCREMENT_005fEXPR"></a>
<a class="index-entry-id" id="index-POSTDECREMENT_005fEXPR"></a>
<a class="index-entry-id" id="index-POSTINCREMENT_005fEXPR"></a>
<a class="index-entry-id" id="index-FIX_005fTRUNC_005fEXPR"></a>
<a class="index-entry-id" id="index-FLOAT_005fEXPR"></a>
<a class="index-entry-id" id="index-COMPLEX_005fEXPR"></a>
<a class="index-entry-id" id="index-CONJ_005fEXPR"></a>
<a class="index-entry-id" id="index-REALPART_005fEXPR"></a>
<a class="index-entry-id" id="index-IMAGPART_005fEXPR"></a>
<a class="index-entry-id" id="index-NON_005fLVALUE_005fEXPR"></a>
<a class="index-entry-id" id="index-NOP_005fEXPR"></a>
<a class="index-entry-id" id="index-CONVERT_005fEXPR"></a>
<a class="index-entry-id" id="index-FIXED_005fCONVERT_005fEXPR"></a>
<a class="index-entry-id" id="index-THROW_005fEXPR"></a>
<a class="index-entry-id" id="index-LSHIFT_005fEXPR"></a>
<a class="index-entry-id" id="index-RSHIFT_005fEXPR"></a>
<a class="index-entry-id" id="index-BIT_005fIOR_005fEXPR"></a>
<a class="index-entry-id" id="index-BIT_005fXOR_005fEXPR"></a>
<a class="index-entry-id" id="index-BIT_005fAND_005fEXPR"></a>
<a class="index-entry-id" id="index-TRUTH_005fANDIF_005fEXPR"></a>
<a class="index-entry-id" id="index-TRUTH_005fORIF_005fEXPR"></a>
<a class="index-entry-id" id="index-TRUTH_005fAND_005fEXPR"></a>
<a class="index-entry-id" id="index-TRUTH_005fOR_005fEXPR"></a>
<a class="index-entry-id" id="index-TRUTH_005fXOR_005fEXPR"></a>
<a class="index-entry-id" id="index-POINTER_005fPLUS_005fEXPR"></a>
<a class="index-entry-id" id="index-POINTER_005fDIFF_005fEXPR"></a>
<a class="index-entry-id" id="index-PLUS_005fEXPR"></a>
<a class="index-entry-id" id="index-MINUS_005fEXPR"></a>
<a class="index-entry-id" id="index-MULT_005fEXPR"></a>
<a class="index-entry-id" id="index-WIDEN_005fMULT_005fEXPR"></a>
<a class="index-entry-id" id="index-MULT_005fHIGHPART_005fEXPR"></a>
<a class="index-entry-id" id="index-RDIV_005fEXPR"></a>
<a class="index-entry-id" id="index-TRUNC_005fDIV_005fEXPR"></a>
<a class="index-entry-id" id="index-FLOOR_005fDIV_005fEXPR"></a>
<a class="index-entry-id" id="index-CEIL_005fDIV_005fEXPR"></a>
<a class="index-entry-id" id="index-ROUND_005fDIV_005fEXPR"></a>
<a class="index-entry-id" id="index-TRUNC_005fMOD_005fEXPR"></a>
<a class="index-entry-id" id="index-FLOOR_005fMOD_005fEXPR"></a>
<a class="index-entry-id" id="index-CEIL_005fMOD_005fEXPR"></a>
<a class="index-entry-id" id="index-ROUND_005fMOD_005fEXPR"></a>
<a class="index-entry-id" id="index-EXACT_005fDIV_005fEXPR"></a>
<a class="index-entry-id" id="index-LT_005fEXPR"></a>
<a class="index-entry-id" id="index-LE_005fEXPR"></a>
<a class="index-entry-id" id="index-GT_005fEXPR"></a>
<a class="index-entry-id" id="index-GE_005fEXPR"></a>
<a class="index-entry-id" id="index-EQ_005fEXPR"></a>
<a class="index-entry-id" id="index-NE_005fEXPR"></a>
<a class="index-entry-id" id="index-ORDERED_005fEXPR"></a>
<a class="index-entry-id" id="index-UNORDERED_005fEXPR"></a>
<a class="index-entry-id" id="index-UNLT_005fEXPR"></a>
<a class="index-entry-id" id="index-UNLE_005fEXPR"></a>
<a class="index-entry-id" id="index-UNGT_005fEXPR"></a>
<a class="index-entry-id" id="index-UNGE_005fEXPR"></a>
<a class="index-entry-id" id="index-UNEQ_005fEXPR"></a>
<a class="index-entry-id" id="index-LTGT_005fEXPR"></a>
<a class="index-entry-id" id="index-MODIFY_005fEXPR"></a>
<a class="index-entry-id" id="index-INIT_005fEXPR"></a>
<a class="index-entry-id" id="index-COMPOUND_005fEXPR"></a>
<a class="index-entry-id" id="index-COND_005fEXPR"></a>
<a class="index-entry-id" id="index-CALL_005fEXPR"></a>
<a class="index-entry-id" id="index-STMT_005fEXPR"></a>
<a class="index-entry-id" id="index-BIND_005fEXPR"></a>
<a class="index-entry-id" id="index-LOOP_005fEXPR"></a>
<a class="index-entry-id" id="index-EXIT_005fEXPR"></a>
<a class="index-entry-id" id="index-CLEANUP_005fPOINT_005fEXPR"></a>
<a class="index-entry-id" id="index-CONSTRUCTOR"></a>
<a class="index-entry-id" id="index-COMPOUND_005fLITERAL_005fEXPR"></a>
<a class="index-entry-id" id="index-SAVE_005fEXPR"></a>
<a class="index-entry-id" id="index-TARGET_005fEXPR"></a>
<a class="index-entry-id" id="index-VA_005fARG_005fEXPR"></a>
<a class="index-entry-id" id="index-ANNOTATE_005fEXPR"></a>

<dl class="table">
<dt><code class="code">NEGATE_EXPR</code></dt>
<dd><p>These nodes represent unary negation of the single operand, for both
integer and floating-point types.  The type of negation can be
determined by looking at the type of the expression.
</p>
<p>The behavior of this operation on signed arithmetic overflow is
controlled by the <code class="code">flag_wrapv</code> and <code class="code">flag_trapv</code> variables.
</p>
</dd>
<dt><code class="code">ABS_EXPR</code></dt>
<dd><p>These nodes represent the absolute value of the single operand, for
both integer and floating-point types.  This is typically used to
implement the <code class="code">abs</code>, <code class="code">labs</code> and <code class="code">llabs</code> builtins for
integer types, and the <code class="code">fabs</code>, <code class="code">fabsf</code> and <code class="code">fabsl</code>
builtins for floating point types.  The type of abs operation can
be determined by looking at the type of the expression.
</p>
<p>This node is not used for complex types.  To represent the modulus
or complex abs of a complex value, use the <code class="code">BUILT_IN_CABS</code>,
<code class="code">BUILT_IN_CABSF</code> or <code class="code">BUILT_IN_CABSL</code> builtins, as used
to implement the C99 <code class="code">cabs</code>, <code class="code">cabsf</code> and <code class="code">cabsl</code>
built-in functions.
</p>
</dd>
<dt><code class="code">ABSU_EXPR</code></dt>
<dd><p>These nodes represent the absolute value of the single operand in
equivalent unsigned type such that <code class="code">ABSU_EXPR</code> of <code class="code">TYPE_MIN</code>
is well defined.
</p>
</dd>
<dt><code class="code">BIT_NOT_EXPR</code></dt>
<dd><p>These nodes represent bitwise complement, and will always have integral
type.  The only operand is the value to be complemented.
</p>
</dd>
<dt><code class="code">TRUTH_NOT_EXPR</code></dt>
<dd><p>These nodes represent logical negation, and will always have integral
(or boolean) type.  The operand is the value being negated.  The type
of the operand and that of the result are always of <code class="code">BOOLEAN_TYPE</code>
or <code class="code">INTEGER_TYPE</code>.
</p>
</dd>
<dt><code class="code">PREDECREMENT_EXPR</code></dt>
<dt><code class="code">PREINCREMENT_EXPR</code></dt>
<dt><code class="code">POSTDECREMENT_EXPR</code></dt>
<dt><code class="code">POSTINCREMENT_EXPR</code></dt>
<dd><p>These nodes represent increment and decrement expressions.  The value of
the single operand is computed, and the operand incremented or
decremented.  In the case of <code class="code">PREDECREMENT_EXPR</code> and
<code class="code">PREINCREMENT_EXPR</code>, the value of the expression is the value
resulting after the increment or decrement; in the case of
<code class="code">POSTDECREMENT_EXPR</code> and <code class="code">POSTINCREMENT_EXPR</code> is the value
before the increment or decrement occurs.  The type of the operand, like
that of the result, will be either integral, boolean, or floating-point.
</p>
</dd>
<dt><code class="code">FIX_TRUNC_EXPR</code></dt>
<dd><p>These nodes represent conversion of a floating-point value to an
integer.  The single operand will have a floating-point type, while
the complete expression will have an integral (or boolean) type.  The
operand is rounded towards zero.
</p>
</dd>
<dt><code class="code">FLOAT_EXPR</code></dt>
<dd><p>These nodes represent conversion of an integral (or boolean) value to a
floating-point value.  The single operand will have integral type, while
the complete expression will have a floating-point type.
</p>
<p>FIXME: How is the operand supposed to be rounded?  Is this dependent on
<samp class="option">-mieee</samp>?
</p>
</dd>
<dt><code class="code">COMPLEX_EXPR</code></dt>
<dd><p>These nodes are used to represent complex numbers constructed from two
expressions of the same (integer or real) type.  The first operand is the
real part and the second operand is the imaginary part.
</p>
</dd>
<dt><code class="code">CONJ_EXPR</code></dt>
<dd><p>These nodes represent the conjugate of their operand.
</p>
</dd>
<dt><code class="code">REALPART_EXPR</code></dt>
<dt><code class="code">IMAGPART_EXPR</code></dt>
<dd><p>These nodes represent respectively the real and the imaginary parts
of complex numbers (their sole argument).
</p>
</dd>
<dt><code class="code">NON_LVALUE_EXPR</code></dt>
<dd><p>These nodes indicate that their one and only operand is not an lvalue.
A back end can treat these identically to the single operand.
</p>
</dd>
<dt><code class="code">NOP_EXPR</code></dt>
<dd><p>These nodes are used to represent conversions that do not require any
code-generation.  For example, conversion of a <code class="code">char*</code> to an
<code class="code">int*</code> does not require any code be generated; such a conversion is
represented by a <code class="code">NOP_EXPR</code>.  The single operand is the expression
to be converted.  The conversion from a pointer to a reference is also
represented with a <code class="code">NOP_EXPR</code>.
</p>
</dd>
<dt><code class="code">CONVERT_EXPR</code></dt>
<dd><p>These nodes are similar to <code class="code">NOP_EXPR</code>s, but are used in those
situations where code may need to be generated.  For example, if an
<code class="code">int*</code> is converted to an <code class="code">int</code> code may need to be generated
on some platforms.  These nodes are never used for C++-specific
conversions, like conversions between pointers to different classes in
an inheritance hierarchy.  Any adjustments that need to be made in such
cases are always indicated explicitly.  Similarly, a user-defined
conversion is never represented by a <code class="code">CONVERT_EXPR</code>; instead, the
function calls are made explicit.
</p>
</dd>
<dt><code class="code">FIXED_CONVERT_EXPR</code></dt>
<dd><p>These nodes are used to represent conversions that involve fixed-point
values.  For example, from a fixed-point value to another fixed-point value,
from an integer to a fixed-point value, from a fixed-point value to an
integer, from a floating-point value to a fixed-point value, or from
a fixed-point value to a floating-point value.
</p>
</dd>
<dt><code class="code">LSHIFT_EXPR</code></dt>
<dt><code class="code">RSHIFT_EXPR</code></dt>
<dd><p>These nodes represent left and right shifts, respectively.  The first
operand is the value to shift; it will always be of integral type.  The
second operand is an expression for the number of bits by which to
shift.  Right shift should be treated as arithmetic, i.e., the
high-order bits should be zero-filled when the expression has unsigned
type and filled with the sign bit when the expression has signed type.
Note that the result is undefined if the second operand is larger
than or equal to the first operand&rsquo;s type size. Unlike most nodes, these
can have a vector as first operand and a scalar as second operand.
</p>

</dd>
<dt><code class="code">BIT_IOR_EXPR</code></dt>
<dt><code class="code">BIT_XOR_EXPR</code></dt>
<dt><code class="code">BIT_AND_EXPR</code></dt>
<dd><p>These nodes represent bitwise inclusive or, bitwise exclusive or, and
bitwise and, respectively.  Both operands will always have integral
type.
</p>
</dd>
<dt><code class="code">TRUTH_ANDIF_EXPR</code></dt>
<dt><code class="code">TRUTH_ORIF_EXPR</code></dt>
<dd><p>These nodes represent logical &ldquo;and&rdquo; and logical &ldquo;or&rdquo;, respectively.
These operators are not strict; i.e., the second operand is evaluated
only if the value of the expression is not determined by evaluation of
the first operand.  The type of the operands and that of the result are
always of <code class="code">BOOLEAN_TYPE</code> or <code class="code">INTEGER_TYPE</code>.
</p>
</dd>
<dt><code class="code">TRUTH_AND_EXPR</code></dt>
<dt><code class="code">TRUTH_OR_EXPR</code></dt>
<dt><code class="code">TRUTH_XOR_EXPR</code></dt>
<dd><p>These nodes represent logical and, logical or, and logical exclusive or.
They are strict; both arguments are always evaluated.  There are no
corresponding operators in C or C++, but the front end will sometimes
generate these expressions anyhow, if it can tell that strictness does
not matter.  The type of the operands and that of the result are
always of <code class="code">BOOLEAN_TYPE</code> or <code class="code">INTEGER_TYPE</code>.
</p>
</dd>
<dt><code class="code">POINTER_PLUS_EXPR</code></dt>
<dd><p>This node represents pointer arithmetic.  The first operand is always
a pointer/reference type.  The second operand is always an unsigned
integer type compatible with sizetype.  This and POINTER_DIFF_EXPR are
the only binary arithmetic operators that can operate on pointer types.
</p>
</dd>
<dt><code class="code">POINTER_DIFF_EXPR</code></dt>
<dd><p>This node represents pointer subtraction.  The two operands always
have pointer/reference type.  It returns a signed integer of the same
precision as the pointers.  The behavior is undefined if the difference
of the two pointers, seen as infinite precision non-negative integers,
does not fit in the result type.  The result does not depend on the
pointer type, it is not divided by the size of the pointed-to type.
</p>
</dd>
<dt><code class="code">PLUS_EXPR</code></dt>
<dt><code class="code">MINUS_EXPR</code></dt>
<dt><code class="code">MULT_EXPR</code></dt>
<dd><p>These nodes represent various binary arithmetic operations.
Respectively, these operations are addition, subtraction (of the second
operand from the first) and multiplication.  Their operands may have
either integral or floating type, but there will never be case in which
one operand is of floating type and the other is of integral type.
</p>
<p>The behavior of these operations on signed arithmetic overflow is
controlled by the <code class="code">flag_wrapv</code> and <code class="code">flag_trapv</code> variables.
</p>
</dd>
<dt><code class="code">WIDEN_MULT_EXPR</code></dt>
<dd><p>This node represents a widening multiplication.  The operands have
integral types with same <var class="var">b</var> bits of precision, producing an
integral type result with at least <em class="math">2<var class="var">b</var></em> bits of precision.
The behaviour is equivalent to extending both operands, possibly of
different signedness, to the result type, then multiplying them.
</p>
</dd>
<dt><code class="code">MULT_HIGHPART_EXPR</code></dt>
<dd><p>This node represents the &ldquo;high-part&rdquo; of a widening multiplication.
For an integral type with <var class="var">b</var> bits of precision, the result is
the most significant <var class="var">b</var> bits of the full <em class="math">2<var class="var">b</var></em> product.
Both operands must have the same precision and same signedness.
</p>
</dd>
<dt><code class="code">RDIV_EXPR</code></dt>
<dd><p>This node represents a floating point division operation.
</p>
</dd>
<dt><code class="code">TRUNC_DIV_EXPR</code></dt>
<dt><code class="code">FLOOR_DIV_EXPR</code></dt>
<dt><code class="code">CEIL_DIV_EXPR</code></dt>
<dt><code class="code">ROUND_DIV_EXPR</code></dt>
<dd><p>These nodes represent integer division operations that return an integer
result.  <code class="code">TRUNC_DIV_EXPR</code> rounds towards zero, <code class="code">FLOOR_DIV_EXPR</code>
rounds towards negative infinity, <code class="code">CEIL_DIV_EXPR</code> rounds towards
positive infinity and <code class="code">ROUND_DIV_EXPR</code> rounds to the closest integer.
Integer division in C and C++ is truncating, i.e. <code class="code">TRUNC_DIV_EXPR</code>.
</p>
<p>The behavior of these operations on signed arithmetic overflow, when
dividing the minimum signed integer by minus one, is controlled by the
<code class="code">flag_wrapv</code> and <code class="code">flag_trapv</code> variables.
</p>
</dd>
<dt><code class="code">TRUNC_MOD_EXPR</code></dt>
<dt><code class="code">FLOOR_MOD_EXPR</code></dt>
<dt><code class="code">CEIL_MOD_EXPR</code></dt>
<dt><code class="code">ROUND_MOD_EXPR</code></dt>
<dd><p>These nodes represent the integer remainder or modulus operation.
The integer modulus of two operands <code class="code">a</code> and <code class="code">b</code> is
defined as <code class="code">a - (a/b)*b</code> where the division calculated using
the corresponding division operator.  Hence for <code class="code">TRUNC_MOD_EXPR</code>
this definition assumes division using truncation towards zero, i.e.
<code class="code">TRUNC_DIV_EXPR</code>.  Integer remainder in C and C++ uses truncating
division, i.e. <code class="code">TRUNC_MOD_EXPR</code>.
</p>
</dd>
<dt><code class="code">EXACT_DIV_EXPR</code></dt>
<dd><p>The <code class="code">EXACT_DIV_EXPR</code> code is used to represent integer divisions where
the numerator is known to be an exact multiple of the denominator.  This
allows the backend to choose between the faster of <code class="code">TRUNC_DIV_EXPR</code>,
<code class="code">CEIL_DIV_EXPR</code> and <code class="code">FLOOR_DIV_EXPR</code> for the current target.
</p>
</dd>
<dt><code class="code">LT_EXPR</code></dt>
<dt><code class="code">LE_EXPR</code></dt>
<dt><code class="code">GT_EXPR</code></dt>
<dt><code class="code">GE_EXPR</code></dt>
<dt><code class="code">LTGT_EXPR</code></dt>
<dt><code class="code">EQ_EXPR</code></dt>
<dt><code class="code">NE_EXPR</code></dt>
<dd><p>These nodes represent the less than, less than or equal to, greater than,
greater than or equal to, less or greater than, equal, and not equal
comparison operators.  The first and second operands will either be both
of integral type, both of floating type or both of vector type, except for
LTGT_EXPR where they will only be both of floating type.  The result type
of these expressions will always be of integral, boolean or signed integral
vector type.  These operations return the result type&rsquo;s zero value for false,
the result type&rsquo;s one value for true, and a vector whose elements are zero
(false) or minus one (true) for vectors.
</p>
<p>For floating point comparisons, if we honor IEEE NaNs and either operand
is NaN, then <code class="code">NE_EXPR</code> always returns true and the remaining operators
always return false.  On some targets, comparisons against an IEEE NaN,
other than equality and inequality, may generate a floating-point exception.
</p>
</dd>
<dt><code class="code">ORDERED_EXPR</code></dt>
<dt><code class="code">UNORDERED_EXPR</code></dt>
<dd><p>These nodes represent non-trapping ordered and unordered comparison
operators.  These operations take two floating point operands and
determine whether they are ordered or unordered relative to each other.
If either operand is an IEEE NaN, their comparison is defined to be
unordered, otherwise the comparison is defined to be ordered.  The
result type of these expressions will always be of integral or boolean
type.  These operations return the result type&rsquo;s zero value for false,
and the result type&rsquo;s one value for true.
</p>
</dd>
<dt><code class="code">UNLT_EXPR</code></dt>
<dt><code class="code">UNLE_EXPR</code></dt>
<dt><code class="code">UNGT_EXPR</code></dt>
<dt><code class="code">UNGE_EXPR</code></dt>
<dt><code class="code">UNEQ_EXPR</code></dt>
<dd><p>These nodes represent the unordered comparison operators.
These operations take two floating point operands and determine whether
the operands are unordered or are less than, less than or equal to,
greater than, greater than or equal to, or equal respectively.  For
example, <code class="code">UNLT_EXPR</code> returns true if either operand is an IEEE
NaN or the first operand is less than the second.  All these operations
are guaranteed not to generate a floating point exception.  The result
type of these expressions will always be of integral or boolean type.
These operations return the result type&rsquo;s zero value for false,
and the result type&rsquo;s one value for true.
</p>
</dd>
<dt><code class="code">MODIFY_EXPR</code></dt>
<dd><p>These nodes represent assignment.  The left-hand side is the first
operand; the right-hand side is the second operand.  The left-hand side
will be a <code class="code">VAR_DECL</code>, <code class="code">INDIRECT_REF</code>, <code class="code">COMPONENT_REF</code>, or
other lvalue.
</p>
<p>These nodes are used to represent not only assignment with &lsquo;<samp class="samp">=</samp>&rsquo; but
also compound assignments (like &lsquo;<samp class="samp">+=</samp>&rsquo;), by reduction to &lsquo;<samp class="samp">=</samp>&rsquo;
assignment.  In other words, the representation for &lsquo;<samp class="samp">i += 3</samp>&rsquo; looks
just like that for &lsquo;<samp class="samp">i = i + 3</samp>&rsquo;.
</p>
</dd>
<dt><code class="code">INIT_EXPR</code></dt>
<dd><p>These nodes are just like <code class="code">MODIFY_EXPR</code>, but are used only when a
variable is initialized, rather than assigned to subsequently.  This
means that we can assume that the target of the initialization is not
used in computing its own value; any reference to the lhs in computing
the rhs is undefined.
</p>
</dd>
<dt><code class="code">COMPOUND_EXPR</code></dt>
<dd><p>These nodes represent comma-expressions.  The first operand is an
expression whose value is computed and thrown away prior to the
evaluation of the second operand.  The value of the entire expression is
the value of the second operand.
</p>
</dd>
<dt><code class="code">COND_EXPR</code></dt>
<dd><p>These nodes represent <code class="code">?:</code> expressions.  The first operand
is of boolean or integral type.  If it evaluates to a nonzero value,
the second operand should be evaluated, and returned as the value of the
expression.  Otherwise, the third operand is evaluated, and returned as
the value of the expression.
</p>
<p>The second operand must have the same type as the entire expression,
unless it unconditionally throws an exception or calls a noreturn
function, in which case it should have void type.  The same constraints
apply to the third operand.  This allows array bounds checks to be
represented conveniently as <code class="code">(i &gt;= 0 &amp;&amp; i &lt; 10) ? i : abort()</code>.
</p>
<p>As a GNU extension, the C language front-ends allow the second
operand of the <code class="code">?:</code> operator may be omitted in the source.
For example, <code class="code">x ? : 3</code> is equivalent to <code class="code">x ? x : 3</code>,
assuming that <code class="code">x</code> is an expression without side effects.
In the tree representation, however, the second operand is always
present, possibly protected by <code class="code">SAVE_EXPR</code> if the first
argument does cause side effects.
</p>
</dd>
<dt><code class="code">CALL_EXPR</code></dt>
<dd><p>These nodes are used to represent calls to functions, including
non-static member functions.  <code class="code">CALL_EXPR</code>s are implemented as
expression nodes with a variable number of operands.  Rather than using
<code class="code">TREE_OPERAND</code> to extract them, it is preferable to use the
specialized accessor macros and functions that operate specifically on
<code class="code">CALL_EXPR</code> nodes.
</p>
<p><code class="code">CALL_EXPR_FN</code> returns a pointer to the
function to call; it is always an expression whose type is a
<code class="code">POINTER_TYPE</code>.
</p>
<p>The number of arguments to the call is returned by <code class="code">call_expr_nargs</code>,
while the arguments themselves can be accessed with the <code class="code">CALL_EXPR_ARG</code>
macro.  The arguments are zero-indexed and numbered left-to-right.
You can iterate over the arguments using <code class="code">FOR_EACH_CALL_EXPR_ARG</code>, as in:
</p>
<div class="example smallexample">
<pre class="example-preformatted">tree call, arg;
call_expr_arg_iterator iter;
FOR_EACH_CALL_EXPR_ARG (arg, iter, call)
  /* arg is bound to successive arguments of call.  */
  ...;
</pre></div>

<p>For non-static
member functions, there will be an operand corresponding to the
<code class="code">this</code> pointer.  There will always be expressions corresponding to
all of the arguments, even if the function is declared with default
arguments and some arguments are not explicitly provided at the call
sites.
</p>
<p><code class="code">CALL_EXPR</code>s also have a <code class="code">CALL_EXPR_STATIC_CHAIN</code> operand that
is used to implement nested functions.  This operand is otherwise null.
</p>
</dd>
<dt><code class="code">CLEANUP_POINT_EXPR</code></dt>
<dd><p>These nodes represent full-expressions.  The single operand is an
expression to evaluate.  Any destructor calls engendered by the creation
of temporaries during the evaluation of that expression should be
performed immediately after the expression is evaluated.
</p>
</dd>
<dt><code class="code">CONSTRUCTOR</code></dt>
<dd><p>These nodes represent the brace-enclosed initializers for a structure or an
array.  They contain a sequence of component values made out of a vector of
constructor_elt, which is a (<code class="code">INDEX</code>, <code class="code">VALUE</code>) pair.
</p>
<p>If the <code class="code">TREE_TYPE</code> of the <code class="code">CONSTRUCTOR</code> is a <code class="code">RECORD_TYPE</code>,
<code class="code">UNION_TYPE</code> or <code class="code">QUAL_UNION_TYPE</code> then the <code class="code">INDEX</code> of each
node in the sequence will be a <code class="code">FIELD_DECL</code> and the <code class="code">VALUE</code> will
be the expression used to initialize that field.
</p>
<p>If the <code class="code">TREE_TYPE</code> of the <code class="code">CONSTRUCTOR</code> is an <code class="code">ARRAY_TYPE</code>,
then the <code class="code">INDEX</code> of each node in the sequence will be an
<code class="code">INTEGER_CST</code> or a <code class="code">RANGE_EXPR</code> of two <code class="code">INTEGER_CST</code>s.
A single <code class="code">INTEGER_CST</code> indicates which element of the array is being
assigned to.  A <code class="code">RANGE_EXPR</code> indicates an inclusive range of elements
to initialize.  In both cases the <code class="code">VALUE</code> is the corresponding
initializer.  It is re-evaluated for each element of a
<code class="code">RANGE_EXPR</code>.  If the <code class="code">INDEX</code> is <code class="code">NULL_TREE</code>, then
the initializer is for the next available array element.
</p>
<p>In the front end, you should not depend on the fields appearing in any
particular order.  However, in the middle end, fields must appear in
declaration order.  You should not assume that all fields will be
represented.  Unrepresented fields will be cleared (zeroed), unless the
CONSTRUCTOR_NO_CLEARING flag is set, in which case their value becomes
undefined.
</p>
</dd>
<dt><a class="index-entry-id" id="index-COMPOUND_005fLITERAL_005fEXPR_005fDECL"></a>
<a id="index-COMPOUND_005fLITERAL_005fEXPR_005fDECL_005fEXPR"></a><span><code class="code">COMPOUND_LITERAL_EXPR</code><a class="copiable-link" href="#index-COMPOUND_005fLITERAL_005fEXPR_005fDECL_005fEXPR"> &para;</a></span></dt>
<dd><p>These nodes represent ISO C99 compound literals.  The
<code class="code">COMPOUND_LITERAL_EXPR_DECL_EXPR</code> is a <code class="code">DECL_EXPR</code>
containing an anonymous <code class="code">VAR_DECL</code> for
the unnamed object represented by the compound literal; the
<code class="code">DECL_INITIAL</code> of that <code class="code">VAR_DECL</code> is a <code class="code">CONSTRUCTOR</code>
representing the brace-enclosed list of initializers in the compound
literal.  That anonymous <code class="code">VAR_DECL</code> can also be accessed directly
by the <code class="code">COMPOUND_LITERAL_EXPR_DECL</code> macro.
</p>
</dd>
<dt><code class="code">SAVE_EXPR</code></dt>
<dd>
<p>A <code class="code">SAVE_EXPR</code> represents an expression (possibly involving
side effects) that is used more than once.  The side effects should
occur only the first time the expression is evaluated.  Subsequent uses
should just reuse the computed value.  The first operand to the
<code class="code">SAVE_EXPR</code> is the expression to evaluate.  The side effects should
be executed where the <code class="code">SAVE_EXPR</code> is first encountered in a
depth-first preorder traversal of the expression tree.
</p>
</dd>
<dt><code class="code">TARGET_EXPR</code></dt>
<dd><p>A <code class="code">TARGET_EXPR</code> represents a temporary object.  The first operand
is a <code class="code">VAR_DECL</code> for the temporary variable.  The second operand is
the initializer for the temporary.  The initializer is evaluated and,
if non-void, copied (bitwise) into the temporary.  If the initializer
is void, that means that it will perform the initialization itself.
</p>
<p>Often, a <code class="code">TARGET_EXPR</code> occurs on the right-hand side of an
assignment, or as the second operand to a comma-expression which is
itself the right-hand side of an assignment, etc.  In this case, we say
that the <code class="code">TARGET_EXPR</code> is &ldquo;normal&rdquo;; otherwise, we say it is
&ldquo;orphaned&rdquo;.  For a normal <code class="code">TARGET_EXPR</code> the temporary variable
should be treated as an alias for the left-hand side of the assignment,
rather than as a new temporary variable.
</p>
<p>The third operand to the <code class="code">TARGET_EXPR</code>, if present, is a
cleanup-expression (i.e., destructor call) for the temporary.  If this
expression is orphaned, then this expression must be executed when the
statement containing this expression is complete.  These cleanups must
always be executed in the order opposite to that in which they were
encountered.  Note that if a temporary is created on one branch of a
conditional operator (i.e., in the second or third operand to a
<code class="code">COND_EXPR</code>), the cleanup must be run only if that branch is
actually executed.
</p>
</dd>
<dt><code class="code">VA_ARG_EXPR</code></dt>
<dd><p>This node is used to implement support for the C/C++ variable argument-list
mechanism.  It represents expressions like <code class="code">va_arg (ap, type)</code>.
Its <code class="code">TREE_TYPE</code> yields the tree representation for <code class="code">type</code> and
its sole argument yields the representation for <code class="code">ap</code>.
</p>
</dd>
<dt><code class="code">ANNOTATE_EXPR</code></dt>
<dd><p>This node is used to attach markers to an expression. The first operand
is the annotated expression, the second is an <code class="code">INTEGER_CST</code> with
a value from <code class="code">enum annot_expr_kind</code>, the third is an <code class="code">INTEGER_CST</code>.
</p></dd>
</dl>


</div>
<hr>
<div class="nav-panel">
<p>
Next: <a href="Vectors.html">Vectors</a>, Previous: <a href="Storage-References.html">References to storage</a>, Up: <a href="Expression-trees.html">Expressions</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html" title="Index" rel="index">Index</a>]</p>
</div>



</body>
</html>
